ERP - мнение о результатах внедрения, позитивно или негативно Часть 2
======================================================================== КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4333 от 2007-02-09 участников 1789 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Здравствуйте, Федор.
Ф> Внедряли ИНФИН и он как бы внедрен но за ним глаз да глаз нужен, Ф> т.е. прежде чем использовать пересчитай и перепроверь. Ф> При внедрение был конкретный разговор руководства (зам. Ф> по экономике и глав.бух) что они хотят видеть от системы. Ф> Было конкретно рассказано как построена работа сейчас Ф> какие отчеты и какие документы есть, кто за что отвечает.
После внедрения САПа на в нашей корпорации. могу сказать, что как конкретно осуществлялся выбор системы не знаю. Но первоначально ее обкатали на одном из ал. заводов, среднем по размеру. А после поставили на все остальные. Видя размеры и возможности могу сказать, что в первую очередь надо определить объемы работы системы. такая как САП - наиболее подойдет для крупных и очень крупных организаций (в РЖД САП тоже стоит), они это себе могут позволить и уровень качества, подогнав с помощью АВАР по свои нужды все настройки.
Ф> внедренцы. в любой системе есть четкое разделение прав доступа к Ф> документа (кто-то может только читать кто-то может делать все Ф> кто-то ничего) тут только либо все либо ничего :) - а на четко Ф> поставленный вопрос как с правами доступа директор внедренцев Ф> четко соврал все классно, как хотите так можете и давать.
Сейчас работаем в системе 3ий год. настройки по ограничениям доступа сразу были, жестко ограниченные. чаще приходилось выбивать новые полномочия на доступ у группы поддержки. одной из первых проблем (но это техническая) было, то что при огромной детализации и объемах, не хватало мощности серверов на удовлетворительную скорость обработки данных.
теперь о результах, которые наблюдаю с рабочего места, как руководитель группы САП на отдельном заводе (в ситеме работают и другие, но крупнее сейчас нет, есть такие же по объемам). Все данные вводятся с рабочих мест и там же могут получать отчеты, т.е. скорость представления отчетных данных и их детализация увеличилась. это относится и к процессу бюджетирования и к инвест-проектам и к налоговой отчетности. количество людей задействованных в формировании управленческой и бухгалтерской отчетности уменьшилось, т.к. большинство данных человек вводит сразу на рабочем месте не передавая оператору, а также сам их контролирует и классифицирует при вводе. остается момент использования этих данных топ-менеджерами. а одним из итогов, если это им является - на мой взгляд - да - это объединение РУСАЛа и СУАЛа.
-- С уважением, Илья mailto:NIKON@BAZ.RU
-*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4334 от 2007-02-09 участников 1814 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> AR> Я повторяю - меня устраивают консалтеры и внедренцы, РЕШАЮЩИЕ > AR> задачу за которую они берутся и меня меньше всего волнуют ИХ > AR> проблемы КАК решить мои задачи - я за это им плачу. Как я могу > AR> принять решение грамотно, если в ПО и инструментарии разбираетесь > AR> вы? Я беру на себя ответственность, за то как вы потом мне > AR> автоматизируете хаос? О, тогда безусловно, решение за мной - а вы > AR> чисты аки голуби - в любой ситуации. > AR> > AR> Опять же - когда приходишь в аптеку и спрашиваешь лекарство от > AR> стресса, например - обязательно порекомендуют какой нибудь дорогой > AR> новопассит или суперстресс не менее чем за 100 рублей, тогда как > AR> валерьянка стоит копейки и настолько же эффективна. > > Господа, ну это же смешно! **** Максим, это не смешно, а страшно, что до сих пор фирмы не выстраивают долгосрочные отношения с клиентом, а качают с него деньги подобно насосу.
> Естественно, что консалтеры зарабатывают на клиентах - бизнес есть > бизнес. ***** Бизнес это когда товар-деньги-товар, а не дрянь-деньги. Я понимаю совершенно четко, что использование клиентом системы зависит в том числе и от клиента, однако тут можно привести аналогию с оборудованием: поставщик ставит оборудование, монтирует его, обеспечивает пуско-наладку, показывает выход на проектную мощность и честно получает деньги. А дальше уже проблема клиента. В нашем случае же ситуация зачастую иная: внедренцы ставят систему, якобы показывают что она налажена и работает отдельными элементами, за каждый элемент получают деньги и подпись клиента "претензий не имею" и сворачиваются. А клиент остается с системой один на один и безусловно не удовлетворен результатами. Один из важнейших показателей эффективности работы внедренцев - удовлетворенность клиента, а мы даже тут в форуме наблюдаем обратную реакцию чуть ли не в 80% случаев. Я пока тут не читал ни одного отзыва о том, что хотя бы кто нибудь остался доволен работой внедренцев. О чем это говорит? Возможно о бестолковости клиента. согласен, но внедренцы же являются еще и консультантами по бизнес-технологиям и сами же утверждают, что ЕРП меняет структуры и сложившиеся бизнес-процессы чуть ли не на 50%. Клиент платит деньги за то чтобы эти изменения были к лучшему, чтобы получив отчет консультантов и попробовав поработать он понял, что это действительно удобнее.
> Но возмущаться их нечестностью - это тоже самое, что возмущаться > пирамидками типа МММ - "какие нехорошие, денежку взяли, золотые горы пообещали - и ПШИК, обманули меня, глупенького". Сами же "фантики" покупали, да еще и в очередях стояли, вложиться хотели. Вы же не бабушки с советским менталитетом. Рынок на дворе. ***** Хорошее сравнение с МММ. Мне понравилось. Все прочитали? Не хотите лохануться - не обращайтесь к консалтерам и внедренцам, а сами обучайтесь, господа - Вы же не бабушки, а бизнесмены. Я думаю все таки Вы погорячились сравнив ремесло консалтера с МММ. Мне кажется что настоящий консалтер должен выстраивать отношения с клиентом на стратегически долгий срок - вам же с него кормиться потом. Консалтер или внедренец должен брать на себя ответственность за свои предложения, а ответственность за их реализацию берет на себя клиент. И консалтер точно так же как клиент удостоверяет выполнение работы консалтером должен поэтапно удостоверять, что его предложения клиент выполнил, а результат далее должен анализироваться. И по нему уже следует судить об эффективности мероприятий. Консалтинг очень тяжелое ремесло, но очень необходимое.
> А если Вам консалтеры лапшу вешают, а вы радуетесь - какие же вы > бизнесмены ;) **** А мы не радуемся, а пытаемся обсуждать проблемы которые возникают. В том числе и в этом ДЛ, как видите. И не только обсуждать, а показать что мы, как клиенты хотели бы видеть от консалтеров и внедренцев (бОльшую чем сейчас ответственность за результат вашей работы), а вы должны нам показать заранее свои возможности и их границы, и не кормить пустыми обещаниями. Я к счастью встречал и такие деловые партнерские отношения и могу сказать, что после этого не хочется работать как то иначе - как вы говорите бизнес-есть бизнес.
> Каждый лечится как считает нужным - или новопасситом, или валерьянкой. > Окончательное решение все равно за клиентом. > И если клиент не дурак и не пофигист - пусть потратит недельку -> другую, полистает литературу, с людьми пообщается. > Пусть примет ОСОЗНАННОЕ, РАЦИОНАЛЬНОЕ решение, а потом контролирует > пути его достижения. **** Это сложно. ЕРП - очень большая система, и выполнение каждого этапа не гарантирует работы всего комплекса ЕРП. Именно об этом я и предлагаю все же в дальнейшем дискутировать - эта тема интереснее, чем обижаться клиенту на внедренцев, а внедренцам на клиента. Что толку опять поднимать в ДЛ тему "нравицца-не нравицца", я снова призываю конструктивно мыслить о том, как должны строиться отношения между клиентом-заказчиком, чтобы добиться максимального эффекта (спасибо за план Уайта - это как раз то что нужно, между прочим один мой знакомый консалтер сказал, что этого плана их фирма не придерживается и не знает о нем, хотя его фирма - один из лидеров рынка в Петербурге и Москве. У них свои планы, рекомендованные разработчиками ПО). Опять же следует определиться с обещаниями консалтеров-внедренцев, с критериями их выполнения и с результатом.
> Пока сами клиенты не осознают, чего они хотят в конце концов добиться > путем автоматизации - внедренцы и будут им помогать автоматизировать > хаос. > Необходимое условие, чтобы к чему-то прийти - надо хотя бы начать > идти! Достаточное условие - стремление клиента совершенствоваться и > квалификация консалтера, чтобы помогать ему. ***** Совершенно верно. Квалификация консалтера. Стремления то у клиентов хоть отбавляй, раз они готовы платить абы кому огромные деньги, а вот что подтверждает квалификацию внедренца, как не количество успешно завершенных проектов и удовлетворенные клиенты, которые дают рекомендации. Кстати, все большее количество предприятий именно так и делает - ориентируется на рекомендации а не на ваши обещания и рекламу.
-*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4335 от 2007-02-09 участников 1814 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Доброго дня ,
>> Внедряли ИНФИН и он как бы внедрен но за ним глаз да глаз нужен, >> т.е. прежде чем использовать пересчитай и перепроверь. >> MC> То есть вы хотите сказать, что система при сложении 2+2 в некоторых MC> случаях выдает 4, а в некоторых 5? Или вы не понимаете, как она MC> считает, и не понимаете тех процессов, которые она автоматизирует?
Именно это я и говорю :), причем эти случаи на данный момент известны (т.е. в каких отчетах и когда вероятность получения правильно отчета выше) я понимаю как она считает, программеры понимают как она считает, тока понять не могут почему каждый раз по разному получается. Простой пример:
у нас на предприятии подоговорной учет затрат. заказываю отчет по договору, получаю его, смотрю, не нравится мне пересписание по материалам, иду к экономисту чтоб дать задание на разборку, на что получаю ответ а у меня все нормально и экономист показывает мне распечатку где все в рамках но отчет получен или на час раньше или на день раньше. Вы можете подумать, что, ага подменили что-то, и конечно все изменилось, нет. Договор закрыт в прошедшем месяце а корректировку прошедших периодов может делать только главбух (которая в отпуске) и зам.главбуха которая последний час ничего такого не делала :) садили программмеров и показывали им это, ничего кроме того что мы напишем в Москву и пусть они думают от них получить не удалось.
>> При внедрение был конкретный разговор руководства (зам.по экономике >> и глав.бух) что они хотят видеть от системы. Было конкретно >> рассказано как построена работа сейчас какие отчеты и какие >> документы есть, кто за что отвечает. >> MC> Документы были подписаны? MC> В том числе и как и дополнительные соглашения к договору?
Документы были подписаны, было составлено ТЗ (составляли внедренцы, за что получили копеечку) с нами согласованное. половина отчетов не сделана, от блока складской учет пришлось отказаться, т.к. если по складу такие заморочки пойдут (с остатками материалов постоянно меняющимися) можно контору закрывать сразу
>> Прописаны все функционалки. У нас была локальная автоматизации, >> т.е. каждая служба вела свой учет экономическая управленческий, >> бухгалтерия бухгалтерский на одних и тех же данных (входящих и >> исходящих) >> MC> Хм.. Локальной автоматизацией называется, когда для выполнения MC> одной функции используется одна система.. Из ваших слов следует MC> что организационная структура у вас функциональная, но это MC> никакого отношения к автоматизации не имеет ;)
я же сказал что было :) потому и решили все заавтоматизировать
>> К вопросу о костности, если ты не можешь сделать так - так и скажи >> - нет не могем. Как показала практика это система (Инфина) только >> программа для ведения бух учета причем на малых предприятих (мало >> пользователей мало документов) - вот это то по любому должны знать >> MC> Сделать можно все что угодно, в том числе написать виндоус на MC> ассемблере, если вы готовы оплачивать такие разработки: как MC> написание КИС "с нуля" только для вас, то ИнФин, с радостью бы MC> согласился..
Смысл комментария от меня ускользает, я думаю вы никогда не ставите виндоус на серьезный сервер с секретными данными ;)
>> внедренцы. в любой системе есть четкое разделение прав доступа >> к документа (кто-то может только читать кто-то может делать все >> кто-то ничего) тут только либо все либо ничего :) - а на четко >> поставленный вопрос как с правами доступа директор внедренцев >> четко соврал все классно, как хотите так можете и давать. >> MC> Это обещание документально закреплено? если так, то почему вы MC> заплатили деньги за внедрение, и не потребовали, например, через MC> суд выполнить обещания?
если оговаривать все в договоре, то договор можно писать 100 лет :)
даже если потребовать исполнения обязательств через суд, ни к чему это не приведет, они могут начать составлять отчеты и формы, переделывать их по 100 раз, причем как показала практика настроил отчет, сломал 2 :) кому будет от этого хуже вопрос, а доказать что все так плохо ой как сложно, потому что в суде должно быть мнение эксперта у которого есть право такое мнение высказывать.
>> В общем, это сейчас поплавав в ней 2 года мы понимаем что нас >> обманули и очень сильно, но ничего уже не поделать. :( >> MC> Из ваших слов, пока видны проблемы реализации одного проекта, MC> но какое это отношение имеет ЕРП системам в целом?
в целом имеет отношение, что сама система внедряется для галочки -либо для галочки собственников, либо для галочки внедренцев. второе, что слишком мало мы знаем про эти системы, а кто знает тот молчит в тряпочку Хочется в свою очередь узнать у кого система внедрена и все хорошо. т.е. идет планирование и контроль в полном объеме
MC> Если вам обещали автомобиль бентли новый, попросили за него 10 000 MC> чего-то там, в договоре записали, что будет нечто само ездить и на MC> 4 колесах, в результате вы получили ВАЗ-21053 на ходу, то кто в MC> этом виноват? продавец? мировой автопром? АвтоВАЗ? или собственное MC> желание получить счастье за 10 000?
нет мне обещали автомобиль бентли новый и просили за это 1 000 000, а реально я получил ВАЗ 21053 на ходу но продавцы великодушно согласились снизить цену до 10 000.
MC> Еще раз - не надо думать что ЕРП, КИС или еще какие буквы решит MC> все ваши проблемы, сразу после того, как вы заплатите деньги.. MC> Внедренцы не решают вопросы управления капиталом, они только MC> настраивают инструмент, так как это записано в техническом MC> задании.. Задача адекватно написать ТЗ эта задача общая для MC> внедренцев и клиентов..
И в чем тогда проблема? ТЗ написано, мы его выполняем, осталось добиться выполнения от внедренцев, но ни же не взяли с нас деньги за то что не выполнили и это как они считают честно. А валить все на потребителя с Вашей стороны не очень корректно и делать выводы не соответствующие фактам дискуссии, чистой воды фантазия ;)
-- Ф¨дор
-*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4336 от 2007-02-09 участников 1814 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
>> Каждый лечится как считает нужным - или новопасситом, или >> валерьянкой. Окончательное решение все равно за клиентом. И если >> клиент не дурак и не пофигист - пусть потратит недельку - другую, >> полистает литературу, с людьми пообщается. Пусть примет ОСОЗНАННОЕ, >> РАЦИОНАЛЬНОЕ решение, а потом контролирует пути его достижения.
Тогда надо говорить о том, как правильно делать проект по внедрению ЕРП..
Ну что ж, примерная методика есть, но это, как и план Уайта, методики вендоров просто формализованный здравый смысл.. А именно: 1. проекты автоматизировать бессмысленно, автоматизировать нужно процессы. 2. необходимо определить задачи автоматизации (далеко не факт, что реальные задачи совпадают с декларируемыми, на этом этапе должны в большей степени работать инициаторы проекта, это этап выполняется одновременно с этапом 3) 3. необходимо описать те процессы, которые решили автоматизировать (описать таким образом, что бы все участники проекта понимали описание однозначно) + описание тестовых примеров 4. подобрать такую систему, функционал которой с описанными процессами в наибольшей степени совпадает (тут можно приглашать внедренцев, пусть они показывают как, то что нужно автоматизировать уже реализовано в их системе) - по результатам представления систем выбрать ту которая больше всего к вам подходит 5. собственно внедрение (доработки системы - делает внедренец) 6. обучение персонала 7. тестирование системы на примерах 8. ввод в промышленную эксплуатацию + некоторое время поддержки пункты 5,6 и 7 могут делаться и не последовательно..
Где-то у меня валялся файлик с методикой, написанной внедренцами году в 2003 о том, как построить внедренца.. Если интересно, то могу поискать и сюда кинуть.
-*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4337 от 2007-02-10 участников 1876 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
9 февраля 2007 г. в письме No4335 Федор FM@n*****.ru писал: > у нас на предприятии подоговорной учет затрат. заказываю отчет
Мда, странный случай, если в один и тот же отчет по одним и тем же данным в разное время получается разным.. В общем, действительно вопрос к системе: "какие данные и как вошли в отчет и почему" и к пользователям - кто и когда их вводил...
>>> При внедрение был конкретный разговор руководства (зам.по >>> экономике и глав.бух) что они хотят видеть от системы. Было >>> конкретно рассказано как построена работа сейчас какие отчеты >>> и какие документы есть, кто за что отвечает. >>> MC>> Документы были подписаны? MC>> В том числе и как и дополнительные соглашения к договору? > > Документы были подписаны, было составлено ТЗ (составляли внедренцы, > за что получили копеечку) с нами согласованное. половина отчетов не
> сделана, от блока складской учет пришлось отказаться, т.к. если по > складу такие заморочки пойдут (с остатками материалов постоянно > меняющимися) можно контору закрывать сразу
Тоже странное утверждение, если в договоре или ТЗ написано, что должен формироваться такой-то отчет по таким-то данным и его нет в системе -то можно говорить о неисполнении условий договора..
>>> К вопросу о костности, если ты не можешь сделать так - так и скажи >>> - нет не могем. Как показала практика это система (Инфина) только >>> программа для ведения бух учета причем на малых предприятих (мало >>> пользователей мало документов) - вот это то по любому должны знать >>> MC>> Сделать можно все что угодно, в том числе написать виндоус на MC>> ассемблере, если вы готовы оплачивать такие разработки: как MC>> написание КИС "с нуля" только для вас, то ИнФин, с радостью бы MC>> согласился.. > > Смысл комментария от меня ускользает, я думаю вы никогда не ставите > виндоус на серьезный сервер с секретными данными ;)
Смысл в том, что любая программа, любой файл это последовательность "1" и "0", если есть двоичный редактор, то за некоторое ограниченное, но очень большое время можно создать любой такой файл, в том числе и любую программу, имеющую вид файла..
MC>> Это обещание документально закреплено? если так, то почему вы MC>> заплатили деньги за внедрение, и не потребовали, например, через MC>> суд выполнить обещания? > > если оговаривать все в договоре, то договор можно писать 100 лет :)
Можно не все, а что "в системе должно быть разграничение прав доступа между группами пользователей, группы пользователей формируются администратором системы, который может им присваивать следующие права: и т.д." В ТЗ нужно и можно описать критически важные моменты.. Если вам разграничение прав было необходимо, то странно что вы это не записали в договоре или доп.соглашении (ТЗ)
> даже если потребовать исполнения обязательств через суд, ни к чему > это не приведет, они могут начать составлять отчеты и формы, > переделывать их по 100 раз, причем как показала практика настроил > отчет, сломал 2 :) кому будет от этого хуже вопрос, а доказать что > все так плохо ой как сложно, потому что в суде должно быть мнение > эксперта у которого есть право такое мнение высказывать.
Тоже, скорее всего проблемы управления конкретным проектом.. если сами отказались от некоторых отчетов, или не написали в договоре когда все отчеты должны быть готовы, то странно требовать это от внедренца..
>>> В общем, это сейчас поплавав в ней 2 года мы понимаем что нас >>> обманули и очень сильно, но ничего уже не поделать. :( >>> MC>> Из ваших слов, пока видны проблемы реализации одного проекта, MC>> но какое это отношение имеет ЕРП системам в целом? > > в целом имеет отношение, что сама система внедряется для галочки -> либо для галочки собственников, либо для галочки внедренцев.
Ну так что же тогда вы хотели? проект следует считать успешным, тогда, когда появится "галочка", никто большего вам и не обещал..
Если собственник хочет что бы у него на предприятии была ЕРП система за маленькие деньги, менеджеры не хотят в ней работать, а хотят работать в екселе, то внедренцы смогут их всех удовлетворить, как это и имело место в вашем случае.. По-моему хороший пример того, как поставив реальные задачи (иметь систему для галочки) инициатор проекта обманул участников (иметь ЕРП систему, помогающую работать), а внедренцы за свою работу получили адекватные деньги...
> второе, что слишком мало мы знаем про эти системы, а кто знает тот > молчит в тряпочку > Хочется в свою очередь узнать у кого система внедрена и все хорошо. > т.е. идет планирование и контроль в полном объеме
А вас при выборе системы внедренцы не возили показывать где такая система уже работает и как работает?
MC>> Если вам обещали автомобиль бентли новый, попросили за него MC>> 10 000 чего-то там, в договоре записали, что будет нечто само MC>> ездить и на 4 колесах, в результате вы получили ВАЗ-21053 на MC>> ходу, то кто в этом виноват? продавец? мировой автопром? АвтоВАЗ? MC>> или собственное желание получить счастье за 10 000? > > нет мне обещали автомобиль бентли новый и просили за это 1 000 000, > а реально я получил ВАЗ 21053 на ходу но продавцы великодушно > согласились снизить цену до 10 000.
Не знаю как оно было на самом деле, но почему-то мне кажется, что вначале возникла цена 10 000, а потом ВАЗ 21053 ;)
MC>> Еще раз - не надо думать что ЕРП, КИС или еще какие буквы решит MC>> все ваши проблемы, сразу после того, как вы заплатите деньги.. MC>> Внедренцы не решают вопросы управления капиталом, они только MC>> настраивают инструмент, так как это записано в техническом MC>> задании.. Задача адекватно написать ТЗ эта задача общая для MC>> внедренцев и клиентов.. > > И в чем тогда проблема? ТЗ написано, мы его выполняем, осталось > добиться выполнения от внедренцев, но ни же не взяли с нас деньги за > то что не выполнили и это как они считают честно.
А если кто-то не выполнит договор, по которому вы заплатили существенные деньги вы требовать деньги обратно тоже не будите? странно, что тогда вы, как компания еще существуете ;)
> А валить все на потребителя с Вашей стороны не очень корректно и > делать выводы не соответствующие фактам дискуссии, чистой воды > фантазия ;)
Под клиентом мы с вами понимаем несколько разных людей - я того, кто платит и определяет задачу системы (хотя, его, наверное стоит называть инициатором, спонсором и т.д.), а Вы - главных специалистов компании, на которой будет происходить внедрение - которые подписывают ТЗ, потом работают в системе, получают отчеты.. По большому счету их задача в том, что бы проверить - то что написано в ТЗ отвечает их ожиданиям от системы..
По поводу роли Инициатора - его задача определить цель проекта, найти для ее реализации ресурсы и потом контролировать достижение это самой цели.. В том числе определить какие части ТЗ будут реализованы, а какие нет. Все-таки не специалисты компании а именно он должен это решать.. Скорее всего в вашем случае так и получилось, просто главных специалистов не проинформировали о том, что на самом деле будет в системе и почему..
-*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4338 от 2007-02-11 участников 1876 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> Где-то у меня валялся файлик с методикой, написанной внедренцами > году в 2003 о том, как построить внедренца.. Если интересно, то > могу поискать и сюда кинуть.
А вот и этот файлик:
=============================== цитата ===============================
Памятка руководителю проекта внедрения или "Как бороться с внедренцами?" (данная памятка составлена в интересах заказчиков информационных систем)
От автора:
"...Я старался написать памятку о том, как выявить недостатки системы и заставить внедренцев их исправить, как переложить риски внедрения на самих же внедренцев..."
Лучший отзыв оппонентов памятки: "...Памятка совсем стала похоже на руководство, как опустить на деньги компанию внедренцев в арбитражном суде..."
Необходимо:
1. Получить и изучить демо-версию системы и документацию на систему, по возможности ознакомиться с практическим опытом эксплуатации системы на сходном предприятии. Можно также предусмотреть настройку некоего пилота под предприятие это будет 3-4 человеко-месяца по трудозатратам, но выполнять эту работу бесплатно, естественно, внедренцы не будут.
2. Создать собственную группу внедрения, определить перечень ключевых пользователей системы. Эта группа должна быть создана приказом по предприятию, ключевые пользователи должны быть заинтересованы во внедрении и понимать, что не менее 30% рабочего времени они должны будут отдать внедрению.
3. Провести полноценное обучение ключевых пользователей работе в системе до закупки каких-либо модулей системы и до подписания контракта на внедрение системы. (Это позволит своевременно предъявить внедренцам требования на доработку системы или отказаться от внедрения неподходящей системы). Контраргумент: в общем неплохо, но для западной системы 1 человеко-день обучения - $300 без проезда и проживания. До подписания контракта потратить эти денежки...
4. Проводить только поэтапное внедрение системы. Проводить только поэтапную закупку модулей и рабочих мест системы в соответствии с планом внедрения. За весь софт сразу платить нельзя, надо оплачивать только необходимые рабочие места. Это будет хоть какой-то рычаг давления на внедренцев: если не исправят ошибок в первом модуле, можно пригрозить не покупать следующие модули. Контраргумент: все бы хорошо, если бы модули были независимы друг от друга. В реалиях - они сильно "завязаны" между собой, внедрять только один, не учитывая при этом цепочку других, неправильно. А учитывать, не имея всех лицензий, не получится. Почему бы не разбить проект на этапы и платить Исполнителю поэтапно? Правда это тоже, скорее всего, не спасет...
5. Оговорить пункт по приведению наименований всех полей на формах и в отчетах к терминологии, принятой на предприятии. Этот пункт позволит сразу выявить несоответствие понятий системы с реальностью заказчика. Контраргумент: однако, одним из плюсов стандартной приличной системы может быть привнесение передового бизнес-опыта. Да, не всегда это плюс, но есть ли уверенность в том, что ваша терминология правильна?
6. Оговорить состав передаваемой документации на систему, правила проверки и приемки документации.
7. Составить полный реестр выходных форм системы (первичных документов и отчетов), подготовить шаблоны выходных форм, правила формирования и образцы заполнения выходных форм. Утвердить правила проверки и приемки формирования выходных форм в системе. Фактически речь идет о разработке репозитория документов (база документационного обеспечения), который может дополняться на этапах информационной диагностики, в ходе разработки ТЗ и использоваться для анализа соответствия требований Заказчика возможностям системы. Контраргумент: замечательно, если реестр выходных форм вы сделаете сами до начала проекта! Этим вы сэкономите время внедренцам, а заодно и дадите им железный аргумент не делать более ничего!
8. Потребовать от внедренцев реестр уже готовых отчетов/первичных документов, которые есть в системе и их описание. Сравнить свой собственный реестр и реестром внедренцев.
9. Заранее оговорить все вопросы, связанные с импортом/экспортом данных. Сначала самим разобраться, а что конкретно мы хотим импортировать/экспортировать. Будет ли это разовая операция или лучше заказать постоянно действующую процедуру?
10. Не забыть согласовать ценовую политику: сколько стоит один отчет (или сколько стоит каждый из отчетов по реестру), сколько стоит передача в Excel одного первичного документа, сколько стоит импорт данных, сколько стоит исправление наименования одного поля на формах. Естественно, что все эти цены должны быть согласованы до оплаты лицензии за систему. Эти цены никогда не должны устанавливаться исходя из времени, которое на них тратят внедренцы. Цена всегда должна быть объявлена за конкретный отчет, первичный документ, процедуру импорта (идея ценовой политики: платить только за ощутимый результат, а не за час трудозатрат). Именно для того, чтобы установить четкие цены на эти работы и необходимо составить возможно более полные реестры и описания задач (внедренцам же надо будет как-то определится с ценой).
11. Разработать сквозные тестовые примеры работы с системой. Тестовый пример включает в себя полностью заполненные документы и порядок ввода/получения одних документов на основе других, перечень функций, которые должны выполняться системой.
12. Оговорить разработку тестовых примеров, как один из результатов проведения диагностики предприятия. Не пожалеть денег на проведение диагностики, разработку тестовых примеров и обучение пользователей. (Диагностика это то, что делают внедренцы за деньги заказчика перед тем, как сформулировать ему свои технические предложения. Самому заказчику от диагностики мало пользы, однако можно попробовать исправить это положение путем разработки тестовых примеров для дальнейшего использования при приемке системы).
13. Утвердить тестовые примеры у ключевых пользователей и внедренцев системы при подписании контракта на внедрение системы.
14. Тщательно продумать кто и как будет осуществлять поддержку и сопровождение системы (имеются ввиду свои сотрудники). Подумать о курсах повышения квалификации для них, подключить их к работе по внедрению с самого начала проекта.
15. Предусмотреть возможность приобретения исходного кода системы (и поставку документации на русском языке, описывающей структуру данных и классы системы).
16. Оговорить наличие в системе "элементарных" удобств, таких как: - сортировка и двойная сортировка строк в таблице (в п.12 таблица это grid то, что видит пользователь), - фильтры строк в таблицах, - настройка скрыть/показать столбцов в таблице, - настройка ширины и порядка следования столбцов в таблице, - пользовательская настройка значений, подставляемых по умолчанию, - slavelookup-ные поля (lookup это выбор из открывающегося списка, slavelookup это поля, сопутствующие выбранному, например выбрали договор по его номеру, хотим сразу видеть его дату, тип, контрагента, причем всегда текущее актуальное значение сопутствующих полей), - автоматическое обновление данных на всех открытых формах системы (при одновременной работе нескольких пользователей с одними и теми же данными), - поиск (по несортированному списку), быстрый поиск (поиск ближайшего значения), поиск в "дереве", - копирование ячеек, - копирование строк в таблицах, - прямая вставка данных из Excel (из буфера обмена), настройка нескольких вариантов вставки из Excel (соответствие столбцов в таблицах системы и столбцов в Excel), - групповые операции по выделенному списку строк: удалить, изменить столбец, специальные групповые операции (например, провести, зарезервировать и прочее). - наличие в системе таких компонентов как: редактируемый grid, иерархический grid, иерархический lookup, - автоподбор lookup по текстовому значению, введенному с клавиатуры, - переход по lookup в связанную таблицу (на которую ссылаемся из данной таблицы), - хранение файлов в системе, - вставка файла путем перетаскивания файла мышкой из папок Windows в систему, - передать в Excel выделенные строки таблицы, - выделить все в таблице, - передача всех выходных форм в Excel, - возможность пользовательских настроек шаблонов выходных форм цвет, шрифт, центрирование текста и прочее.
17. Оговорить в контракте возможность полной настройки прав доступа. Все виды прав (просмотр, добавление, изменение, запуск) на все элементы системы (таблицы, записи, функции). Контраргумент: эти возможности технически труднореализуемы и редко используются на практике.
18. Оговорить в контракте возможность ведения логов работы пользователей. Контраргумент: эти возможности редко используются на практике.
19. Оговорить в контракте возможность замены физического удаления записей на их аннулирование (логическое удаление), возможность просмотра истории изменения атрибутов системы. Контраргумент: эти возможности технически труднореализуемы и редко используются на практике.
20. Не следует забывать и о таких требованиях к системе, как масштабируемость, развиваемость (наличие встроенных средств разработки и модификации системы) и надежность.
21. Приемку системы осуществлять на основе подготовленных тестовых примеров, отдельно по следующим пунктам: - Приемка самой системы: форм для ввода и просмотра данных, функций, правильных наименований полей. - Приемка выходных (печатных) форм системы: отчетов и первичных документов, включая передачу в Excel, пользовательские настройки шаблонов документов. - Приемка документации на систему: руководства пользователя, руководства по администрированию системы, описание структур данных и классов системы. Контраргумент: обычно пишется "Программа и методика испытания", и далее по пунктам...
22. Никогда не планировать разработку отчетов только на последнем этап внедрения системы. Каждый из этапов внедрения должен заканчиваться внедрением соответствующей отчетности (естественно, что могут этапы обследований, проектирования, когда говорить про внедрение отчетности еще преждевременно).
23. Никогда не соглашаться на самостоятельную разработку всех отчетов и настройку форм по требованию пользователей. Контраргумент: вам выставят такие счета, что сразу захотите все сделать сами.
24. Никогда не соглашаться на самостоятельное документирование системы. Дополнения: пока систему внедряют внедренцы, они ее и документируют, если в дальнейшем система модифицируется силами отдела АСУ, документировать придется самим.
25. Всегда требовать возможности последующей самостоятельной разработки новых и модификации существующих отчетов. (И пользоваться этими возможностями после передачи системы в промышленную эксплуатацию).
Типовые уловки внедренцев:
1. Уловка 1. Завышение цены диагностики. Стоимость диагностики может оказаться существенно выше разумных пределов. Особенно круто возрастает стоимость диагностики при любой попытке вписать в результаты диагностики какой-либо пункт, кроме абстрактного отчета о диагностике или рекомендаций. Все эти отчеты и рекомендации у внедренцев уже есть в готовом виде, чуть-чуть подправил и все готово. Другое дело составить реестр отчетов, подготовить шаблоны отчетов и их описание, не говоря уже про подготовку тестовых примеров работы с системой, которые в дальнейшем можно будет использовать при приемке системы. Но ведь именно пример работы системы может показать логику преобразования данных (например, из первичного документа в отчет), которая, в конечном счете, и требуется от системы. В такой ситуации можно посоветовать еще раз подумать о цене системы и ее ценности для предприятия. Если сама диагностика стоит так дорого, то сколько же будет стоить модификация системы и приведение ее в соответствие с требованиями заказчика? Можно так же применять различные схемы оплаты диагностики (50% сразу, 50% в случае подписания основного контракта). Часть работ по подготовке реестра и описания отчетов и разработке тестовых примеров придется поручить ключевым пользователям (бывает очень трудно объяснить людям, что это действительно важно, что на это надо тратить время, еще труднее убедить руководство предприятия выделить определенный объем времени для ключевых пользователей и оплатить их труд).
Комментарий: эта уловка получила неоднозначную оценку на форуме (при обсуждении). Довольно трудно оценить объективную стоимость результатов диагностики.
2. Уловка 2. У нас есть методика, которая успешно применялась во многих проектах, давайте ее применять и в вашем проекте.
Идея применять проверенные методики заслуживает всеобщего одобрения, однако под этим флагом обычно пытаются протащить сокращение четкого описания бизнес-требований к системе. Например, согласно методике внедренцев, разработка тестовых примеров должна происходить уже после закупки лицензий. Зачем вам такая методика? Почему нельзя тестовые примеры работы системы разработать до закупки самой системы, ведь они просто отражают логику вашего бизнеса? Слепо верить методикам внедренцев скользкий путь, так как, не имея показательных примеров, утвержденных в самом начале внедрения, на этапе приемки-сдачи очень трудно обоснованно предъявлять претензии внедренцам.
Комментарий: эта уловка получила контраргументы на форуме: внедренцы могут иметь проработанные и вполне заслуживающие доверия сценарии внедрения. Некоторые "внедренцы" в ходе проекта разрабатывают методику реализации проекта, в которой формализуют все процедуры мониторинга проекта, анализа эффективности, порядка представления и сдачи отчетной, рабочей документации и т.д. В солидных компаниях-интеграторах это обычная практика! Кроме того, разработка тестовых примеров отражающих логику вашего бизнеса весьма дорогостоящее занятие.
3. Уловка 3. Мы выявим ваши бизнес-требования с помощью функциональных моделей, диаграмм потоков, формализованных описаний и пр.
Нет ничего плохого в построении функциональных моделей, диаграмм потоков и каких-либо иных формализованных описаний. Однако следует помнить, что все эти модели предназначены для профессиональных разработчиков программного обеспечения. Если вы считаете себя профессионалом в разработке ПО, то можете смело подписывать и утверждать все эти чудесные модели. А если вы (или ваши ключевые пользователи) являются профессионалами в другой области, то лучше просто принять участие в моделировании, но не подписывать эти модели. Ну как вы можете осознать, как та или иная стрелочка в IDEF/UML/ARIS/ER-модели скажется на работе системы? Будет ли это удобным? Бизнес-требования лучше выявлять на тестовых примерах (или экранных формах, прототипе системы), так как именно тестовые примеры вам наиболее понятны.
Комментарий: Эта уловка вообще не получила никаких отзывов в интернет-дискуссии.
4. Уловка 4. Если вы такие умные, то сами замечательно внедрите систему, да еще и денег сэкономите, а мы вас всему научим, мы вам все покажем.
Это откровенный обман. Нельзя научится внедрять современную ERP-систему, просто прослушав недельный курс обучения. После недельного курса обучения далеко не все ключевые пользователи смогут просто работать в системе, им потребуется не один месяц, чтобы, наконец, разобраться в обычном вводе данных и понять, как эти данные затем попадают в отчеты или используются в расчетных процедурах (как пелось в одной веселой песенке: "Совершите вы массу открытий, иногда не желая того...").
Внедрение системы действительно сложный процесс, которым должны заниматься профессионалы. Если вы все-таки решитесь на самостоятельное внедрение, то вам придется самостоятельно собирать команду внедренцев, причем только из тех людей, которые уже имеют опыт внедрения данной системы.
Комментарий: Эта уловка получила как положительные, так и отрицательные отзывы в интернет-дискуссии. По-видимому, это связано большим разнообразием систем автоматизации, обладающих различной степенью сложности. Чем больше сложность системы, тем меньше шансы на успешное самостоятельное внедрение системы.
5. Уловка 5. В нашей системе так много готовых отчетов, и, кроме того, есть специализированный построитель отчетов, так что не волнуйтесь, все нужные вам отчеты уже есть, а все остальные отчеты вы легко можете добавить самостоятельно.
Это тоже обман. Конечно, есть шанс, что некоторые из готовых отчетов подойдут и вам. Но это надо обязательно проверить до закупки лицензий. В конечном итоге, наличие реестра отчетов, согласованного с внедренцами, гораздо лучшая гарантия того, что эти отчеты действительно будут в системе. Дело в том, что структура хранения данных в системе может как позволять получать нужные вам отчеты, так и не позволять, если в процессе внедрения эта структура не была модифицирована в соответствии с вашими потребностями. Лучший способ проверки просто получите из системы все отчеты при ее приемке. Если вы не убедились в наличии всех отчетов в системе вы рискуете вообще никогда не получить нужных вам отчетов и никакой специализированный построитель отчетов вам уже не поможет.
Комментарий: Эта уловка получила только отрицательные отзывы в интернет-дискуссии, то есть такие уловки на практике не встречаются или исправляются путем приобретения внешних средств построения отчетности, таких как CristalReport или XL Report Builder.
6. Уловка 6. Вместе с нашей системой вы приобретаете весь мировой опыт организации бизнес-процессов да еще и в автоматизированном виде.
Верить этому нельзя. Это надо проверять. Так ли лучше этот самый мировой опыт, и вообще есть ли он в системе? Вполне может быть, что этот опыт не идет дальше красивых презентаций системы перед руководством предприятия. Сама презентация делается с одной целью продать систему. Если, к примеру, с помощью системы предполагается осуществлять планирование закупок по новому принципу, то было бы неплохо задаться вопросом: а откуда берутся данные для этого, а правда ли, что мы реально (то есть в нашей реальной жизни) можем собрать эти данные в том самом виде, как этого требует система, а так ли легко модифицировать результаты планирования, то есть выполнять перепланирование. Может оказаться, что система умеет более менее правильно планировать закупки/производство/сбыт, но в ней нет возможности оперативной АВТОМАТИЧЕСКОЙ коррекции этих планов, то есть, планируем автоматически, а затем вручную все корректируем, да еще и вручную обеспечиваем соответствие планов закупки с планом производства и пр. Трудоемкость коррекции может быть ОЧЕНЬ высокой.
Комментарий: Эта уловка получила положительный отзыв в интернет- дискуссии.
7. Уловка 7. Да вы поймите, говорят внедренцы, это не мы вам внедряем систему, вы сами ее внедряете, а мы вам помогаем, советуем, и вообще все делаем для вашего блага.
Внедрение ERP-систем это бизнес, который далеко не всегда идет на пользу заказчикам. Зачастую руководители предприятий оказываются совершенно не компетентны в вопросах выбора и внедрения систем и становятся жертвами рекламных компаний, развернутых внедренцами. Практическое отсутствие четких, полных, документально оформленных требований к системе со стороны заказчика (заказчик просто не может их сформулировать) приводит к бесконтрольности действий внедренцев и ничем не ограниченной стоимости внедренческих работ. При этом оказывается, что заказчик, платя деньги за систему, становится жертвой собственных инвестиций. Он все больше и больше вязнет в проекте, так и не получая реально работающей системы. Когда стоимость затрат на лицензии и внедрение превышает все мыслимые пределы, внедрение останавливается, проект замораживается, а заказчик наконец-то начинает подсчитывать убытки. Наступает печальный момент, когда надо объяснить руководству, что несколько сотен тысяч долларов оказались неэффективно потрачены на систему. Что ж, такова цена бизнеса на глупости заказчиков. Если вы попались на эту уловку, то можете считать, что вы просто приобрели бесценный опыт и следующий проект автоматизации будет более удачным.
Комментарий: Эта уловка получила отрицательный отзыв в интернет- дискуссии.
О возможном использовании данной памятки.
1. Можно, к примеру, откорректировать эту памятку по собственному усмотрению и выслать ее потенциальным внедренцам, чтобы посмотреть, что они про все это скажут? Пусть пообещают, что они белые, пушистые, очень смирные и послушные.
2. Соблюдение всех правил, перечисленных в памятке, в принципе возможно, но потребует от менеджеров таких затрат по времени, что вопрос целесообразности встает ребром. А потом еще и компетентность, которую можно встретить только в случае, когда директором предприятия становится бывший АСУ-шник.
3. Есть обратная сторона данного вопроса, если появится, а он наверняка появится, какой-то новый, но кране необходимый отчет, все внедренцы как один скажут, что данная работа не входила в перечень, договора. Тоже самое, если появится новая процедура. Более рамочный договор позволит этого избежать, если заказчик достаточно грамотный. С одним я согласен точно, что за весь софт платить нельзя, а необходимо проплачивать только необходимые рабочие места! К тому же трудозатраты по созданию такого договора сравнимы с написанием ТЗ на весь проект. То есть это и есть это собственно и есть ТЗ.
4. Создается впечатление, что многое в памятке предназначено не столько для скорейшего эффективного внедрения системы, сколько именно для борьбы (или войны) с "подлыми внедренцами". Например, некоторые "элементарные удобства" из пункта 12 не во всех системах в принципе реализуемы (или реализация очень трудоемка), однако вряд ли их можно назвать жизненно необходимыми для работы системы. Однако "упершись" в такого рода пункты можно за деревьями не увидеть леса, то бишь возрастает вероятность ошибиться в выборе программы или превратить процесс внедрения в постоянные боевые действия. Впрочем, если подписать с внедренцами контракт, включающий все эти пункты, и, постоянно размахивая им как топором, периодически снисходительно идти на мелкие уступки, то, может быть, в этом и есть смысл.
5. В конечном итоге борьба с внедренцами не единственная задача
руководителя проекта внедрения. Однако не следует ни слишком увлекаться, ни пренебрегать перечнем задач, на которые в данной памятке рекомендуется обратить внимание.
6. Памятка может применяться и как средство давления на заказчика системы. Если заказчик согласился очень четко и детально описать свои требования с самого начала внедрения системы, то именно это он и получит в готовом виде. Ни больше, ни меньше, буква в букву как это написано в ТЗ. А умеете ли вы так четко и однозначно формулировать свои требования? Причем требования придется формулировать не на языке бизнес-логики, а в терминах самой системы, чтобы избежать их неоднозначного трактования (это
касается в первую очередь описания функций и операций в системе, именно их труднее всего описывать на языке, понятном внедренцам)?
Заключение.
Соблюдение вышеперечисленных пунктов, конечно, позволит своевременно выявить несоответствие системы нуждам заказчика, однако, в конечном итоге, внедренцы непобедимы. Ну не станут же они переделывать систему только потому, что она не соответствует потребностям конкретного заказчика. А добиться этого в полном объеме сверхзадача даже для руководителя проекта внедрения.
Ключевые критерии успеха внедрения:
1. Заинтересованность и поддержка высшего менеджмента.
2. Определ¨нность целей и задач, которые должны быть решены в результате внедрения
3. Выбор системы исходя из потребностей предприятия (а не в результате откатов, функционала вообще, известности бренда и т.д.).
4. Грамотный выбор команды внедренцев.
5. Максимально четко прописанный план внедрения с описанием результатов каждого этапа (в данном случае ч¨ткость означает не детальность, а именно очевидность формулировок использованных в плане, не допускающих двоякая трактовка, а в случае возникновения такой двоякости позволяет уточнить, что именно имелось ввиду).
6. Создание на предприятии в результате внедрения собственной команды грамотных специалистов по системе.
7. Привлечение 1-2 внешних консультантов, которые будут выступать со стороны Заказчика и оказывать помощь в диалоге с командой внедренцев.
-*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4339 от 2007-02-11 участников 1876 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> Сам руководил проектом и > внедрением на собственном > предприятии. Эффекта нет.
Насчет эффекта, Володя, ты уж слишком грустно загнул.
Эффект есть. Другое дело, что, как недавно прочитал где-то, "человек неправильно устроен с точки зрения любой технической системы".
Вот у меня на одном из объектов чуть ли не каждую неделю мы инициируем совещания, где разбираемся, что и кому надо. А то они привыкли в екселях как хочу так и ворочу. А как начинаешь сводить их вместе, так тут сразу все из разных щелей и вылезает. А бывает и так, что никому и ничего не надо, кроме нас и руководства. И ничего, привыкли, и двигаемся, и даже интересно. Самый натуральный реинжиниринг и контролинг. А какая там политика начинается, вам не передать, Романы писать можно.
-- С уважением Максим С.
-*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4340 от 2007-02-11 участников 1904 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Как "правильно" подойти к проектированию, я думаю, уже все решили. По крайне мере, обсуждение было очень подробным, хотя ничего сложного в этом нет. Только здравый смысл. Гораздо сложнее - как выбрать внедренца. И вопрос совсем не в том, чтобы, как пишет Максим:
> Где-то у меня валялся файлик с методикой, > написанной внедренцами году в 2003 о том, > как построить внедренца..
Ни к чему хорошему это не приведет по определению, если вы заранее настраиваетесь на противостояние. Лучше при выборе платформы и внедренцев использовать несколько достаточно простых правил:
1. Платформа должна быть хорошо проработана и иметь большой опыт внедрения (пример - 1С) 2. Платформу должны знать и обслуживать как можно больше различных фирм-внедренцев 3. Должна быть возможность легко найти и принять на работу специалиста (программиста) по данному продукту.
Причины тоже достаточно просты. ЛЮБАЯ платформа представляет из себя либо набор кубиков "Сделай сам", либо готовое решение, сделанное для некоей идеальной компании, работающей в идеальных условиях. В любом случае это, как правило, продукт, вас не устаивающий, и вы обязательно захотите его сделать "под себя". Кстати, я, как бывший профессиональный разработчик, полностью одобряю внедренцев, предлагающих вам изменить свои стандарты, под те, которые приняты в готовой системе - вам же дешевле будет! Начиная же подгонять систему под себя вы попадаете в ловушку последующего доения вас на предмет "сопровождения", поскольку ни одна новая версия не будет работать на вашей переделанной системе. Проще (но не эффективнее!) установить готовый продукт и регулярно обновлять его по сделанным разработчиками апдейтам. Причем, на хорошем продукте это делается автоматом. Отсюда - два варианта развития событий: 1. Простейший - покупаете готовый продукт и обучаете свой персонал на хороших курсах правильно пользоваться им, одновременно перестраивая свою систему управления и учета под требования продукта. 2. Выбираете наиболее удобный для разработки "набор кубиков" и занимаетесь разработкой самостоятельно под свои интересы. Второй вариант, выглядящий на первый взгляд более эффективным, как правило не заканчивается ничем. Так же, как и разработка специально "под заказ" сторонними консалтерами. Причины вы уже описали почти все. Добавьте только проблемы с дальнейшим сопровождением полученного франкенштейна.
--С уважением, Владимир
-*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4340 от 2007-02-11 участников 1904 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Как "правильно" подойти к проектированию, я думаю, уже все решили. По крайне мере, обсуждение было очень подробным, хотя ничего сложного в этом нет. Только здравый смысл. Гораздо сложнее - как выбрать внедренца. И вопрос совсем не в том, чтобы, как пишет Максим:
> Где-то у меня валялся файлик с методикой, > написанной внедренцами году в 2003 о том, > как построить внедренца..
Ни к чему хорошему это не приведет по определению, если вы заранее настраиваетесь на противостояние. Лучше при выборе платформы и внедренцев использовать несколько достаточно простых правил:
1. Платформа должна быть хорошо проработана и иметь большой опыт внедрения (пример - 1С) 2. Платформу должны знать и обслуживать как можно больше различных фирм-внедренцев 3. Должна быть возможность легко найти и принять на работу специалиста (программиста) по данному продукту.
Причины тоже достаточно просты. ЛЮБАЯ платформа представляет из себя либо набор кубиков "Сделай сам", либо готовое решение, сделанное для некоей идеальной компании, работающей в идеальных условиях. В любом случае это, как правило, продукт, вас не устаивающий, и вы обязательно захотите его сделать "под себя". Кстати, я, как бывший профессиональный разработчик, полностью одобряю внедренцев, предлагающих вам изменить свои стандарты, под те, которые приняты в готовой системе - вам же дешевле будет! Начиная же подгонять систему под себя вы попадаете в ловушку последующего доения вас на предмет "сопровождения", поскольку ни одна новая версия не будет работать на вашей переделанной системе. Проще (но не эффективнее!) установить готовый продукт и регулярно обновлять его по сделанным разработчиками апдейтам. Причем, на хорошем продукте это делается автоматом. Отсюда - два варианта развития событий: 1. Простейший - покупаете готовый продукт и обучаете свой персонал на хороших курсах правильно пользоваться им, одновременно перестраивая свою систему управления и учета под требования продукта. 2. Выбираете наиболее удобный для разработки "набор кубиков" и занимаетесь разработкой самостоятельно под свои интересы. Второй вариант, выглядящий на первый взгляд более эффективным, как правило не заканчивается ничем. Так же, как и разработка специально "под заказ" сторонними консалтерами. Причины вы уже описали почти все. Добавьте только проблемы с дальнейшим сопровождением полученного франкенштейна.
--С уважением, Владимир -*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4341 от 2007-02-11 участников 1904 Написать: economics.school.controlling-list@subscribe.ru ======================================================================== К этому файлику тоже стоит подходить с изрядным скепсисом %)
Зачем? таким образом сы отсеиваем все новые разработки само по себе большое количествео внежрений программного продукта под одним и тем же названием не гарантирует успеха или наличия оптыных специалистов на вашем проекте или специалистов, которые будут разбираться в том, что вы у себя внедрили... Хотя если внедрений мало, то это лишний повод задуматься, почему эту систему никто у себя еще не поставил ;))
> 2. Платформу должны знать и обслуживать как > можно больше различных фирм-внедренцев которые, вообще говоря не факт что разбираются в той системе, которую вы поставили.. Тоже не догма, а как один из вопросов, которые стоит задать- кто будет потом эту систему обслуживать?
> 3. Должна быть возможность легко найти и > принять на работу специалиста (программиста) > по данному продукту. Если система сдела "под вас" то такого специалиста вы точно не найдете.. Скорее это вопросы - которыестоит задать перед выбором - что первично система или ваши бизнес-процессы.. ИМХО, внедрять САП в Усть-Урюпинске можно, если вы саперам будите платить столько, сколько они получают в Москве, В Усть-Урюпинске можно внедрять 1С, ибо и там есть специалисты по 1С, можно внедрять супер-пупер систему Вася и К, ибо все равно специалисты по этой системе от вас никуда не убегут..
> > Причины тоже достаточно просты. ЛЮБАЯ платформа > представляет из себя либо набор кубиков "Сделай > сам", либо готовое решение, сделанное для некоей > идеальной компании, работающей в идеальных > условиях. В любом случае это, как правило, > продукт, вас не устаивающий, и вы обязательно > захотите его сделать "под себя". Кстати, я, как > бывший профессиональный разработчик, полностью > одобряю внедренцев, предлагающих вам изменить > свои стандарты, под те, которые приняты в готовой Только пусть решение примают не внедренцы, а инициатор проекта ибо только он знает зачем система внедряется и стоит ли такое изменение запрашиваемых денег..
-*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4342 от 2007-02-12 участников 1904 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Доброго дня ,
MC> Мда, странный случай, если в один и тот же отчет по одним и тем же MC> данным в разное время получается разным.. В общем, действительно MC> вопрос к системе: MC> "какие данные и как вошли в отчет и почему" MC> и к пользователям - кто и когда их вводил... какой может быть вопрос если человек 2 месяца назад занес сумму оплаты материалов по договру и с тех пор эта сумма не изменялась? даже когда мы начинае разбирать отчет по составляющим, т.н. идем на прямую к цифрам, они как были так месяц назад так и остались :)
>>>> MC>>> Документы были подписаны? MC>>> В том числе и как и дополнительные соглашения к договору? давайте пропишем как еще нужно ходить в туалет чтоб программа работала хорошо :) подпсам договр и акт (акт с перечнем недоработок) да наша вина в том что мы не додавили внедренцев на их устранение, тут наш косяк, но я думаю если вы платите деньги то люди должны делать самим а не после твоих просьб
>> >> Документы были подписаны, было составлено ТЗ (составляли внедренцы, …
была уменьшина сумма по договру. Еще раз повторюсь, то что сайчас чтото работает это далось очень большой ценой
>> >> Смысл комментария от меня ускользает, я думаю вы никогда не ставите ... я знаю что такое асемблер (по первому диплому я програмист) от меня ускользает смысл того, что если человек знает как работает его программа то почему он этого не расказывает.
MC>>> Это обещание документально закреплено? если так, то почему вы…
читай те инструкцию , было нам сказано типа там все есть, как показала практика а так же фраза уточните на какой странице, почему человек больше к нам не заходит или только с директором :)
MC> Тоже, скорее всего проблемы управления конкретным проектом.. если сами MC> отказались от некоторых отчетов, или не написали в договоре когда все MC> отчеты должны быть готовы, то странно требовать это от внедренца.. отказались :), готов выслушать Ваши предложения, что после введения некоторых отчетов почемутопреставали работать другие. Странно а что делать?!
>>>> В общем, это сейчас поплавав в ней 2 года мы понимаем что нас >>>> обманули и очень сильно, но ничего уже не поделать. :( MC>>> Из ваших слов, пока видны проблемы реализации одного проекта, MC>>> но какое это отношение имеет ЕРП системам в целом? Отношение к чему или к кому? Общался с людьми и с внедренцами и с юзерами на других предприятиях, никто даже внедренцы положа руку на сердце говорят както сбагрили и нах..
>> >> в целом имеет отношение, что сама система внедряется для галочки ->> либо для галочки собственников, либо для галочки внедренцев.
MC> Ну так что же тогда вы хотели? проект следует считать успешным, тогда, MC> когда появится "галочка", никто большего вам и не обещал..
давайте не будем вот тут тупить, для ихней галочки.
MC> Если собственник хочет что бы у него на предприятии была ЕРП система MC> за маленькие деньги, менеджеры не хотят в ней работать, а хотят MC> работать в екселе, то внедренцы смогут их всех удовлетворить, как MC> это и имело место в вашем случае.. По-моему хороший пример того, как MC> поставив реальные задачи (иметь систему для галочки) инициатор проекта MC> обманул участников (иметь ЕРП систему, помогающую работать), MC> а внедренцы за свою работу получили адекватные деньги...
маленькие или болшие денги каждое предприятие определяет для себы я думаю по своим доходам ;). Менеджеры хотят в ней работать, все хотят в ней работать и работают но извените меня когда топ менеджер читате отчте по приходу расходу д/с за квартал с помесячной разбивкой, а у него сумму по горизонтали не бьются т.е. янв -1 млн., фев. -1 млн., март - 1 млн, итого по 1 кв 3,5млн и какая это управленческая информация? если честно то лично я реально просто устал воевать с внедренцами, заявок написано кучи толка чуть, ребято просто включают дурочку. не видели, повторите пожалуйста. если интересно могу показать их отчеты по типу, ваш вопрос отправлне в Мск, ждите отвте. Или это проблема решена в новой версии программы, установка новой вервии стоит ХХХ тыс.рублей.
А по поводу цены, ее назначали сами внедренцы, могли скзаать как в 2 раза больше так и в 2 раза меньша, а вот то что вы гворита типа не доплачиват, это плохая нездоровая тенденция образовалась в России, про страны СНГ не скажу, купил себе машину за 100 000 у.е. а в ней магнитола сломалась и поменять не могут уже год, а чего вы хотели от машины за 100 000 у.е. говорят в сервисе.
>> второе, что слишком мало мы знаем про эти системы, а кто знает тот >> молчит в тряпочку >> Хочется в свою очередь узнать у кого система внедрена и все хорошо. >> т.е. идет планирование и контроль в полном объеме
MC> А вас при выборе системы внедренцы не возили показывать где такая MC> система уже работает и как работает? нет, только расказывали. Хотя мжет и были предложения, но я пришел работь когда уже было принято решения было ТЗ и началось внедрение.
MC>>> Если вам обещали автомобиль бентли новый, попросили за него MC>>> 10 000 чего-то там, в договоре записали, что будет нечто само…
нет сначло возникло желание купить автомобиль и пошел мой шеф с этим желанием в автосалон (а точнее на выставку ;) )а там ему сказала вот бери, все просто суппер.
MC>>> Еще раз - не надо думать что ЕРП, КИС или еще какие буквы решит MC>>> все ваши проблемы, сразу после того, как вы заплатите деньги.. MC>>> Внедренцы не решают вопросы управления капиталом, они только MC>>> настраивают инструмент, так как это записано в техническом MC>>> задании.. Задача адекватно написать ТЗ эта задача общая для MC>>> внедренцев и клиентов..
оно написанное. но если яне могу верить в формируемые отчеты как я могу эфективно управлять ресурсами? если видя оплату опять таки миллион и зная план оплаты то нужно платит 3, я делаю прогноз что нужно доплатит будет 2, а фигушки цифра про 1 млн правильная а вот про 3 вранье там 3,5 :)
>> И в чем тогда проблема? ТЗ написано, мы его выполняем, осталось … Да я действительно под клиентами понимаю тех людей которые работают с программой, но работают как по обработке данных так и по потреблению отчетов :) цели сталили у нас главбух, зам по экономике и финансам, начальник управления снабжением. я читал техзадание все очень красиво, просто сказка, но я работаю в этой программе все нетак сказочно :)
MC> По поводу роли Инициатора - его задача определить цель проекта, найти MC> для ее реализации ресурсы и потом контролировать достижение это самой MC> цели.. В том числе определить какие части ТЗ будут реализованы, а MC> какие нет. Все-таки не специалисты компании а именно он должен это MC> решать.. Скорее всего в вашем случае так и получилось, просто главных MC> специалистов не проинформировали о том, что на самом деле будет в MC> системе и почему..
их как раз проинформировали очень красочно, по факту получилось не очень :), но если моего начальника не очень это коснулось, т.к. вся выловка ошибок лежит на мне, то вот главбух она страдает потому как ошики ей ловить приходиться самой :)
PS вспомнил, про некоторые обещания. например про экспорт данных оно выглядело сл. образом есть специальный инструмент для экспорта мы вам все сделаем, но что этот инструмент непрввильно работат никто не говрил ровно как то что он работате правильно :)
-- Ф¨дор
-*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4343 от 2007-02-12 участников 1915 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> какой может быть вопрос если человек 2 месяца назад занес сумму оплаты > материалов по договру и с тех пор эта сумма не изменялась? > даже когда мы начинае разбирать отчет по составляющим, т.н. идем на > прямую к цифрам, они как были так месяц назад так и остались :) **** Разрешите присоединиться? То, о чем пишет Федор - очень распространенная ситуация в системах такого рода. Я думаю, что причина этого - низкая квалификация ведренцев. когда каждый конкретный исполнитель не понимает какова будет роль его работы во всем проекте - грубо говоря, когда отдельный программист владеет только своим куском кода - одним отчетом. и ему не досуг проверить совместимость его отчета с другими. Не получается общей картины - в этом и беда - тогда конечно каждый раз отчеты будут разными, не говоря уже об арифметике. Логической совместимостью отчетов наверняка никто не занимался - я говорю о проверке на совместимость результатов. >
> MC>>> Документы были подписаны? > MC>>> В том числе и как и дополнительные соглашения к договору? > давайте пропишем как еще нужно ходить в туалет чтоб программа работала > хорошо :) > подпсам договр и акт (акт с перечнем недоработок) > да наша вина в том что мы не додавили внедренцев на их устранение, тут > наш косяк, но я думаю если вы платите деньги то люди должны делать > самим а не после твоих просьб **** Именно об этом и я пытался сказать, но как видите - есть мнение, что клиента надо доить, раз он дурачок - вот нас и доят - это же бизнес! Боюсь только что такой бизнес умрет, не родившись толком.
> >> Документы были подписаны, было составлено ТЗ (составляли внедренцы, > >> за что получили копеечку) с нами согласованное. половина отчетов не > >> сделана, от блока складской учет пришлось отказаться, т.к. если по > >> складу такие заморочки пойдут (с остатками материалов постоянно > >> меняющимися) можно контору закрывать сразу > > MC> Тоже странное утверждение, если в договоре или ТЗ написано, что должен формироваться такой-то отчет по таким-то данным и его нет в системе - то можно говорить о неисполнении условий договора.. > была уменьшина сумма по договру. Еще раз повторюсь, то что сайчас > чтото работает это далось очень большой ценой **** Не всегда заранее можно прописать о том какой нужен отчет, потому что сначала многие моменты кажутся простыми и логичными, но потом вступают в противоречие с логикой системы и не могут быть созданы. Пример: Мы просили обеспечить историчность системы - чтобы можно было видеть в какой момент кто внес информацию в систему, чтобы состояние планирования можно было посмотреть в любой момент времени в прошлом. Разработчики сказали - сделаем! Второе пожелание было обеспечить возможность внесения изменений задним числом в управленческую информацию. Разработчики сказали - без проблем! Никто не подумал что эти принципы противоречат друг другу. Это наверное не вина разработчика или клиента - такие моменты проявляются позже. Просто на их расшивку уходить огромная масса времени и сил.
> MC> Смысл в том, что любая программа, любой файл это последовательность > MC> "1" и "0", если есть двоичный редактор, то за некоторое ограниченное, > MC> но очень большое время можно создать любой такой файл, в том числе и > MC> любую программу, имеющую вид файла.. > я знаю что такое асемблер (по первому диплому я програмист) от меня > ускользает смысл того, что если человек знает как работает его > программа то почему он этого не расказывает. ***** Мое мнение такое - человек не знает сам как работает его система, поэтому не может рассказать. "Говорили тебе, Петька, учи пароль - теперь расстреляют ни за грош...". Опять же это от низкой квалификации внедренцев. > > MC>>> Это обещание документально закреплено? если так, то почему вы > MC>>> заплатили деньги за внедрение, и не потребовали, например, через > MC>>> суд выполнить обещания? > >> > >> если оговаривать все в договоре, то договор можно писать 100 лет :) ***** Мы заключали каждый раз дополнительные соглашения, коих накопилось более 100 в процессе работы. Часть из них пришлось оплачивать отдельно, часть признали входящей в условия заключенного договра
> >>>> В общем, это сейчас поплавав в ней 2 года мы понимаем что нас > >>>> обманули и очень сильно, но ничего уже не поделать. :( > >>>> > MC>>> Из ваших слов, пока видны проблемы реализации одного проекта, > MC>>> но какое это отношение имеет ЕРП системам в целом? > Отношение к чему или к кому? > Общался с людьми и с внедренцами и с юзерами на других предприятиях, > никто даже внедренцы положа руку на сердце говорят както сбагрили и > нах.. **** Я тоже это слишком часто встречал. Рабочее время стало уходить на борьбу с системой, пришлось нанимать новых сотрудников, опеспечивать им новые рабочие места, то есь об экономии на трудозатратах речи идти не может.
> Менеджеры хотят в ней работать, все хотят в ней работать и работают но > извените меня когда топ менеджер читате отчте по приходу расходу д/с > за квартал с помесячной разбивкой, а у него сумму по горизонтали не бьются > т.е. янв -1 млн., фев. -1 млн., март - 1 млн, итого по 1 кв 3,5млн > и какая это управленческая информация? > если честно то лично я реально просто устал воевать с внедренцами, > заявок написано кучи толка чуть, ребято просто включают дурочку. > не видели, повторите пожалуйста. если интересно могу показать их > отчеты по типу, ваш вопрос отправлне в Мск, ждите отвте. ***** Ага. а как правило ответ нужен сегодня - чтобы сформировать отчетность для руководства. Знакомое поведение.
> >> второе, что слишком мало мы знаем про эти системы, а кто знает тот > >> молчит в тряпочку > >> Хочется в свою очередь узнать у кого система внедрена и все хорошо. > >> т.е. идет планирование и контроль в полном объеме **** О да! Кто нибудь хотя бы один в ДЛ может сказать что ему внедрили довольно сложную систему в которой он работает и доволен результатом? Желательно без ссылок на СМИ, где пишут что в каком то сименсе все успешно работает - я бы очень удивился если бы неважно какая контора в прессе сокрушалась по поводу того что ничего не работает. Всегда рапорта будут очень радужными.
> MC> А вас при выборе системы внедренцы не возили показывать где такая > MC> система уже работает и как работает? > нет, только расказывали. Хотя мжет и были предложения, но я пришел > работь когда уже было принято решения было ТЗ и началось внедрение. **** Нам показывали элементы системы. И я с тех пор придерживаюсь мнения что автоматизировать предприятие нужно по участкам, желательно по минимуму связывая их между собой - чтобы исключить взаимовлияния. КОнечно справочники и кодировки будут общими, но иногда лучше допустить дублирования ввода информации, чем потом годами мучиться откуда что берется. А уж поскольку персонал имеет привычку увольняться - то система должна быть понятной даже Буратино, чтобы обучение не занимало более 1 дня.
> MC>>> Еще раз - не надо думать что ЕРП, КИС или еще какие буквы решит > MC>>> все ваши проблемы, сразу после того, как вы заплатите деньги.. > MC>>> Внедренцы не решают вопросы управления капиталом, они только > MC>>> настраивают инструмент, так как это записано в техническом > MC>>> задании.. Задача адекватно написать ТЗ эта задача общая для > MC>>> внедренцев и клиентов.. > оно написанное. но если яне могу верить в формируемые отчеты как я > могу эфективно управлять ресурсами? если видя оплату опять таки > миллион и зная план оплаты то нужно платит 3, я делаю прогноз что > нужно доплатит будет 2, а фигушки цифра про 1 млн правильная а вот про > 3 вранье там 3,5 :) **** Тут дело в том, что пока не придумано иного пути, чем поэтапно фиксировать выполненную работу - в результате заказчики часто согласуют этапы работ разработчикам и оплачивают эти этапы. В дальнейшем новые этапы меняют уже созданные вещи, но за этим вряд ли кто следит - отсюда и проблемы. ТЗ тут не спасет - слишком велики взаимосвязи блоков.
> >> И в чем тогда проблема? ТЗ написано, мы его выполняем, осталось > >> добиться выполнения от внедренцев, но ни же не взяли с нас деньги за > >> то что не выполнили и это как они считают честно. > > MC> А если кто-то не выполнит договор, по которому вы заплатили > MC> существенные деньги вы требовать деньги обратно тоже не будите? > MC> странно, что тогда вы, как компания еще существуете ;) *** Исполнитель работ отчитывается по выполненным этапам, которые подписаны заказчиком. подписание всех этапов - ознакает завершение контракта и выполнение обязательств исполнителем. А то что в общем система не работает - уже сложнее доказать в том же суде.
> их как раз проинформировали очень красочно, по факту получилось не > очень :), но если моего начальника не очень это коснулось, т.к. вся > выловка ошибок лежит на мне, то вот главбух она страдает потому как > ошики ей ловить приходиться самой :) ***** Легче всего внедренцам ничего не знающему начальнику объяснить что все в шоколаде - не ему же работать в системе, ему лишь только отчеты получать. Может быть поэтому внедренцы так любят общаться с высшим руководством и требуют его поддержку, а не с непосредственными операторами работы в системе? Всегда же можно объяснить что персонал не подготовлен, что руководство стратегически мыслит, а вот его персонал-подчиненные саботируют работу, глупые и не могут освоить элементарные вещи. Систему надо рассчитывать на среднего клерка, которому работать в системе а не на его начальника.
-*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4344 от 2007-02-12 участников 1915 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> Только пусть решение примают не внедренцы, а инициатор проекта > ибо только он знает зачем система внедряется и стоит ли такое > изменение запрашиваемых денег.
А инициатор проекта это кто? собственник, CEO, CFO CIO или кто-то еще? И зачем ему вообще нужно это внедрение? А если ему действительно что-то нужно, то почему возникают такие проблемы с внедрением?
Хотелось бы получить мнение участников ДЛ по данным вопросам.
-*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4345 от 2007-02-13 участников 1915 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
***** В моем случае инициаторами внедрения ЕРП был Совет Директоров с подачи Вице-Президента по финансам. Совершенно правильно была поставлена задача на высшем уровне, на мой взгляд - обеспечить руководство оперативной информацией о состоянии и развитии компании и каждого из ее филиалов в необходимых управленческих разрезах, на основе имеющейся информации предполагать развитие ситуации и изменения экономических показателей. По финансовому блоку - формировать БДДС каждой структуры компании и всего холдинга в целом, выявлять кассовые разрывы и избыточную ликвидность заранее - чтобы подготовить мероприятия по нивелированию этих факторов. По сырьевому блоку - система должна рассчитывать по производственному плану потребности в каждом виде сырья, должна на основе анализа предложения поставщиков определять наиболее удобный и экономичный график поставок сырья, приближенный к JIT. В продажах - система должна была определять остатки товарных запасов на каждом складе предприятия, учиты вать сроки доставки по регионам и сроки хранения готовой продукции, процент брака на каждой стадии логистической цепочки. Кроме того система должна определять оборот по каждому клиенту и устанавливать ему по формальным признакам систему скидок. По блоку инвестиций система должна была строить график капиталовложений и платежей, как элементы БДР и БДДС всей компании. В системе велись все инвестиционные договора компании, вносилась информация о платежах налом, безналом, через подотчет. Планирование производства - система на этапе планирования производства от плана продаж должна была установить максимально экономичный с точки зрения логистики производственный план, рассчитать потребности в сырье и материалах под него, спрогнозировать остатки на складах и потребность в дополнительном персонале, ну и так далее. Разработчики все приняли и началась реализация по блокам. В принципе молодой коллектив поддержал идею внедрения такой системы и активно участвовал в работе по формализации потоков данных. Первая проблема возникла из-за сроков. Плановый период в 1 год на реализацию системы был перекрыт более чем в 2 раза. При этом и сотрудники компании и представители внедренцев пахали до 22-23 часов, включая выходные. На заседаниях рабочих групп внедренцы прогибались под требования заказчиков по принципу кто наглее тот и первый. Ведь в заседаниях принимали участие представители всех служб компании - и закупок-снабжения и продаж и финансов и т.п. То есть при разработке системы не был установлен порядок осуществления работ (вернее он был сильно нарушен, разными доработками, доделками и тестированием). То есть проблемы возникли 1) из-за недооценки сторонами объема работ 2) из-за перенапряжения участников проекта 3) из-за нарушения принципа очередности выполнения работ 4) из-за непонимания взаимосвязей элементов системы каждым отдельным участником (например реестр закупочных позиций сперва был создан только снабженцами - под свои потребности, но потом потребовал доработки со стороны инвестиционного блока - добавление новых реквизитов и модификацию существующих, что едва не нарушило логику системы). 5) из-за долгого срока ведения работ и сильной ротации кадров в следствие усталости обученная прослойка людей - создателей системы была размыта, новички должны были с места включаться в работу системы, не понимая принципов ее функционирования.
Алексей, Петербург.
> > Только пусть решение примают не внедренцы, а инициатор проекта > > ибо только он знает зачем система внедряется и стоит ли такое > > изменение запрашиваемых денег. > > А инициатор проекта это кто? собственник, CEO, CFO CIO или кто-то еще? И зачем > ему вообще нужно это внедрение? А если ему действительно что-то нужно, то почему > возникают такие проблемы с внедрением? > > Хотелось бы получить мнение участников ДЛ по данным вопросам. > >
-*--------------------------------------------------------------------------КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4346 от 2007-02-13 участников 1915 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
>> какой может быть вопрос если человек 2 месяца назад занес сумму >> оплаты материалов по договру и с тех пор эта сумма не изменялась?
А вы уверены что она в системе не изменялась?
>> даже когда мы начинае разбирать отчет по составляющим, т.н. идем на >> прямую к цифрам, они как были так месяц назад так и остались :)
Вопрос неоднозначный, я бы начал с проверки того, по какой формуле эта сумма считается... И откуда берутся данные для расчета этой самой формулы..
MC>>>>> Документы были подписаны? MC>>>>> В том числе и как и дополнительные соглашения к договору? >> давайте пропишем как еще нужно ходить в туалет чтоб программа >> работала хорошо :) >> подпсам договр и акт (акт с перечнем недоработок) да наша вина в >> том что мы не додавили внедренцев на их устранение, тут наш косяк, >> но я думаю если вы платите деньги то люди должны делать самим а не >> после твоих просьб
В целом, согласен что не все может быть описано, но если что-то написано, то внедренцы имею право эти требования понимать буквально..
> Именно об этом и я пытался сказать, но как видите - есть мнение, что > клиента надо доить, раз он дурачок - вот нас и доят - это же бизнес! > Боюсь только что такой бизнес умрет, не родившись толком.
Ну наличие большого количества Элексиров на рынке говорит об обратном... ;)
>>>> Документы были подписаны, было составлено ТЗ (составляли >>>> внедренцы, за что получили копеечку) с нами согласованное. >>>> половина отчетов не сделана, от блока складской учет пришлось >>>> отказаться, т.к. если по складу такие заморочки пойдут (с >>>> остатками материалов постоянно меняющимися) можно контору >>>> закрывать сразу >> MC>>> Тоже странное утверждение, если в договоре или ТЗ написано, что MC>>> должен формироваться такой-то отчет по таким-то данным и его нет MC>>> в системе - то можно говорить о неисполнении условий договора.. >> была уменьшина сумма по договру. Еще раз повторюсь, то что сайчас >> чтото работает это далось очень большой ценой > Не всегда заранее можно прописать о том какой нужен отчет, потому > что сначала
То есть сейчас вы не знает какие отчеты вы готовите и какие данные для принятия управленческих решений вам нужны?
> многие моменты кажутся простыми и логичными, но потом вступают в > противоречие с логикой системы и не могут быть созданы. Пример: Мы > просили обеспечить историчность системы - чтобы можно было видеть в > какой момент кто внес информацию в систему, чтобы состояние > планирования можно было посмотреть в любой момент времени в прошлом.
По моему это чуть ли не единственное достоинство системы - знать кто какие и когда данные ввел, ИМХО требование обязательное
> Разработчики сказали - сделаем! Второе пожелание было обеспечить > возможность внесения изменений задним числом в управленческую > информацию.
А это зачем? Если такое делать то: 1. достоверность информации теряется; 2. сложность разработки систему увеличивается пропорционально количеству данных и пропорционально квадрату таких пожеланий; 3. скорее всего такие изменения не затронут все отчеты - вы будите либо по разным отчетам получать разные данные либо "править отчеты ручками" как в случае, который рассказал Федор. 4. Смысл внедрения теряется, если человек сможет "непонравившиеся" цифры исправлять руками. Если он видит ошибку в отчете, то пусть ее исправляет не в отчете а в первичных данных.. - тогда уж точно лучше пользуйтесь Екселем..
> Разработчики сказали - без проблем! Никто не подумал что эти > принципы противоречат друг другу. Это наверное не вина разработчика > или клиента - такие моменты проявляются позже. Просто на их расшивку > уходить огромная масса времени и сил. > Вообще говоря они не противоречат друг другу, можно сделать систему, которая каждое нажатие клавиши журналировала, в том числе и корректировки в системе но это больше нужно для прокурора, чем для получения истиной информации..
MC>>> Смысл в том, что любая программа, любой файл это MC>>> последовательность "1" и "0", если есть двоичный редактор, то MC>>> за некоторое ограниченное, но очень большое время можно создать MC>>> любой такой файл, в том числе и любую программу, имеющую вид MC>>> файла... >> я знаю что такое асемблер (по первому диплому я програмист) от меня >> ускользает смысл того, что если человек знает как работает его >> программа то почему он этого не расказывает.
Во-первых не факт что знает, а во-вторых зачем делиться знаниями -теряется незаменимость людей..
MC>>>>> Это обещание документально закреплено? если так, то почему вы MC>>>>> заплатили деньги за внедрение, и не потребовали, например, MC>>>>> через суд выполнить обещания? >>>> >>>> если оговаривать все в договоре, то договор можно писать 100 лет :) > Мы заключали каждый раз дополнительные соглашения, коих накопилось > более 100 в процессе работы. Часть из них пришлось оплачивать > отдельно, часть признали входящей в условия заключенного договра
И что ? Если вам по договору не выполняют оговоренных условий вы тоже так ничего не делаете?
>>>>>> В общем, это сейчас поплавав в ней 2 года мы понимаем что нас >>>>>> обманули и очень сильно, но ничего уже не поделать. :( >>>>>> MC>>>>> Из ваших слов, пока видны проблемы реализации одного проекта, MC>>>>> но какое это отношение имеет ЕРП системам в целом? >> Отношение к чему или к кому?
Какое отношение неудачи одного проекта имеют к тезису что "ЕРП системы мешают управлять предприятием"?
>>> Менеджеры хотят в ней работать, все хотят в ней работать и >>> работают но >> извените меня когда топ менеджер читате отчте по приходу расходу >> д/с за квартал с помесячной разбивкой, а у него сумму по >> горизонтали не бьются т.е. янв -1 млн., фев. -1 млн., март - 1 млн, >> итого по 1 кв 3,5млн и какая это управленческая информация?
Точного ответа дать не могу :), но мне почему-то кажется, что этот отчет готовился ручками.. ;)
>> если честно то лично я реально просто устал воевать с внедренцами, >> заявок написано кучи толка чуть, ребято просто включают дурочку. >> не видели, повторите пожалуйста. если интересно могу показать их >> отчеты по типу, ваш вопрос отправлне в Мск, ждите отвте. > Ага. а как правило ответ нужен сегодня - чтобы сформировать отчетность > для руководства. Знакомое поведение. > >>>> второе, что слишком мало мы знаем про эти системы, а кто знает >>>> тот молчит в тряпочку Хочется в свою очередь узнать у кого >>>> система внедрена и все хорошо. т.е. идет планирование и контроль >>>> в полном объеме
На сколько я знаю в фирме "Торговая Площадь" Аксапта была внедрена к 2003 году и на тот момент большинство людей было довольно.., Вроде про "Чип и Дип" и "МВО" ничего плохого не слышно..
MC>>> А вас при выборе системы внедренцы не возили показывать где MC>>> такая система уже работает и как работает? >> нет, только расказывали. Хотя мжет и были предложения, но я пришел >> работь когда уже было принято решения было ТЗ и началось внедрение. > Нам показывали элементы системы. И я с тех пор придерживаюсь мнения > что ну и на этих референсных площадках говорили что система плохая? тогда почему вы ее выбрали?
MC>>>>> Еще раз - не надо думать что ЕРП, КИС или еще какие буквы MC>>>>> решит все ваши проблемы, сразу после того, как вы заплатите MC>>>>> деньги.. Внедренцы не решают вопросы управления капиталом, они MC>>>>> только настраивают инструмент, так как это записано в MC>>>>> техническом задании.. Задача адекватно написать ТЗ эта задача MC>>>>> общая для внедренцев и клиентов.. >> оно написанное. но если яне могу верить в формируемые отчеты как я >> могу эфективно управлять ресурсами? если видя оплату опять таки >> миллион и зная план оплаты то нужно платит 3, я делаю прогноз что >> нужно доплатит будет 2, а фигушки цифра про 1 млн правильная а вот >> про 3 вранье там 3,5 :)
ИМХО, не знаю точного ответа, но мне кажется, что данные человек подправляет ручками, причем только часть данных а не все, часть этих подправлений попадает в ваш отчет, а часть нет... .
>>>> И в чем тогда проблема? ТЗ написано, мы его выполняем, осталось >>>> добиться выполнения от внедренцев, но ни же не взяли с нас деньги >>>> за то что не выполнили и это как они считают честно. >> MC>>> А если кто-то не выполнит договор, по которому вы заплатили MC>>> существенные деньги вы требовать деньги обратно тоже не будите? MC>>> странно, что тогда вы, как компания еще существуете ;) > Исполнитель работ отчитывается по выполненным этапам, которые > подписаны заказчиком. подписание всех этапов - ознакает завершение > контракта и выполнение обязательств
Этап выполнен, если реализованы все элементы ТЗ на этот этап.. Пишите в акте, что такие-то пункты ТЗ не реализованы, оплата за этот этап работ будет осуществлена после устранения замечаний...
>> их как раз проинформировали очень красочно, по факту получилось не >> очень :), но если моего начальника не очень это коснулось, т.к. вся >> выловка ошибок лежит на мне, то вот главбух она страдает потому как >> ошики ей ловить приходиться самой :) > Легче всего внедренцам ничего не знающему начальнику объяснить что > все в шоколаде - не ему же работать в системе, ему лишь только > отчеты получать. Может
Ну если начальник ничего не знает, то он плохой управленец ;), а вопросы, связанные с ошибками управления никакая система решить не позволит..
> быть поэтому внедренцы так любят общаться с высшим руководством и > требуют его поддержку, а не с непосредственными операторами работы в > системе? Всегда же можно объяснить что персонал не подготовлен, что > руководство стратегически мыслит, а вот его персонал-подчиненные > саботируют работу, глупые и не могут освоить элементарные вещи. > Систему надо рассчитывать на среднего клерка, которому работать в > системе а не на его начальника.
Клерк проверил при подписании акта что система работает? что отчеты формируются и формируются правильно? если так и никто в систему не вносил изменений, то очень странно что система формирует в разное время разные отчеты.. -*--------------------------------------------------------------------------
|
